Rule Examples

This list assembles rule examples. It is just a collection of rules and each rule is explained. In each example, only non-empty fields are listed. To show variable term that should be replaced by the actual values of your own server configuration:

server has to be substituted with your servers name, e.g. www.yourserver.com
serverIP has to be substituted with a folders name for a virtual host
subfolder has to be substituted with a folders name for a virtual host

In the "How it works" section, I will quote ("") any rule text I am talking about.

Private Pictures
Shared and protected cgi-bin folder
Multi-Language Index Files
Redirection of outdated Links

Private Pictures [back]
This rule will prevent others to create links on their pages to pictures on your server. This version restricts access to one virtual host, so you should duplicate it for any virtual host you like to protect.

Path: /subfolder/*.{gif jpg jpeg}
Referer: http://{server serverIP}/*
Execute Condition: <P0>&<!R0>
Path Result: /subfolder/a_transparent.gif
Jump To: stop

How it works:
The "{gif jpg jpeg}" will match any of the three suffixes. I add a "." in front of it and to match only paths that ends in ".xxx"I use a "*" to match anything in fron to of it.
The referer field will only match the servers name or ip number.
To create a boolean expression that will say "a match at Path: and not a match at Referer", I use a "&" to add a AND and inside the second reference I use "!" as NOT. Note, that using "<P0>" or "<R0>" or any other reference with an ending "0" will be very common in the condition field. Compared to e.g. "<P2>" which will be the reference to the second placeholder in the Path: field, "<P0>" will be the boolean result of the question: "Was Welcome able to match all wildcards in the field?".
The result field will simply change the path (whatever it was before) to a path that points to a file in the virtual server root. If you create a transparent 1x1 pixel GIF image and name it "a_transparent.gif"you will have nice results.

Shared and protected cgi-bin folder [back]
This rule is a global rule. It will change all requests to scripts in each virtual hosts to point to the main cgi-bin folder. WebSTAR for example can protect the execution of cgi scripts only if you use the root level cgi-bin folder. To create a workaround, we use this rule to have shared and protected scripts for all virtual hosts.

Path: /[^/]/cgi\-bin/*
Execute Condition: <P0>
Path Result: /cgi-bin/<P1>

How it works:
Assuming, that you only have 1 level deep subfolders for all virtual hosts, the path field will first match anything to the second "/" (this is the "/[^/]" part) and then match the string "cgi-bin/"(we escape the "-" because it is a reserved character) and anything after it. So only URLs like "/welcome/cgi-bin/lasso.acgi$..."will be matched, but not "/foo/test/cgi-bin/cool.html"
The condition is a typical one. It just executes the rule if the path was matched.
In the result, we strip the subfolder by not including it in the string. As you can see, the path starts directly with "/cgi-bin" (note that escaping is only allowed in the wildcard formulars) and adds the reference to the "*" ("<P1>"). A reference will put the text of the wildcard's match in the expression. In this rule, we are just passing the stuff after the "cgi-bin/" string, so it will not modify the path beyond "/cgi-bin/".

Multi-Language Index Files [back]
To show you, that you can create a set of rules for solving a problem, I like to create three rules that will call two different index files - depending on the language(s) the user has set in his/her browser. This needs to have two index files in each directory: instead of "index.html", we use "index-d.html" and "index-e.html". To the outside world, the index file is always "index.html" and no link and no bookmark or printed docs will ever contain "index.html" - even not the html files on the virtual host. The first two rules will detect the language tokens and then change the name of the index file to reflect the language. The third rule will act as a default setting. If rule 1 + 2 fail to detect either "de" or "en", it will rename to index file to your default language (in this example "index-e.html")

Path: /subfolder*/index.html
Language: *en*
Execute Condition: <P0>&<L0>
Path Result: /subfolder<P1>/index-e.html

Path: /subfolder*/index.html
Language: *de*
Execute Condition: <P0>&<L0>
Path Result: /subfolder<P1>/index-d.html

Path: /subfolder*/index.html
Execute Condition: <P0>
Path Result: /subfolder<P1>/index-e.html

How it works:
Rule 1 and 2 are almost the same. They check for a path ending in "/index.html". This will even work with the root index file as the "*" will also match an empty string. If the first rule changes the path, the second rule will not match the "index-e.hml" anymore - this is what we want.
The language field will check if the token string contains either "en"or "de". Because the first rule will check first, a "en"will be prefered if both tokens exist.
Finally, the third rule will only match an unmodified "index.html", so it is only executed if the first and the second rule didn't match.
Note 1: if you don't like to rename all of your index files, but just keep "index.html" as the default language, you can modify the rules to use only a second index file for the other language. This way, you only have to create a second file fore each existing index file.
Note 2: Working with index files is really easy. Even if the path will not contain the index file, but will end in a "/", Welcome is smart enough to add the index file to the path before rules are executed. You never have to deal with two cases.

Redirection of outdated Links [back]
If you have areas on your server that have changed or moved to another server, you will get lots of error hits from search engines or bookmarks. Other tools can redirect a single file, but with Welcome you can redirect any number of grouped files. To do this, you need to know what these files have common in their url path. If you know it, you can set up a rule that will match all files in the group and redirect the request to the right location. This rule will redirect all HTML requests in three different subfolders to another server.

Path: /subfolder/{sales people updates}/*
Execute Condition: <P0>
Path Result: http://www.anotherserver.com/new/<P1>/<P2>
Redirection: checked

How it works:
The path field will match all paths that start with one of your virtual host's subfolder (remember to replace "subfolder" with a real name). The "{sales people updates}" will match (in this case) three different folders and finally the "*" at the end will match anything inside these three folders.
The condition is "<P0>" again - to execute this rule only if the path has really the structure that will match path wildcard formular.
If the condition results in "true", all fields below the condition are evaluated. Path Result will then set the path to a full specified URL including the old folder (one of "sales,"people" or "updates") and the rest of the path.
Note 1: that "<P1>" and "<P2>" will refer to the wildcards used in (P)ath and that "<P1>" will refer to the 1st wildcard ("{sales people updates}") and "<P2>"will refer to the 2nd wildcard ("*") counted from left to right.
The checkbox "Redirection" is used to not modify the path, but to actually send out a redirect to the requesting client. In this case, the request never gets to your server. It will be catched by Welcome.
Note 2: Because of the redirect, rule execution will stop with the first rule that does a redirect. For rules that have the redirection checkbox checked, you don't need to set the jump to field to "stop".

If you have an example of a good rule, or if you like to have a rule added for a problem that you cannot solve, please contact me at pardeike@comcon.de.